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Basic Specification for IP Fast Reroute: Loop-Free Alternates 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document describes the use of loop-free alternates to provide 
local protection for unicast traffic in pure IP and MPLS/LDP networks 
in the event of a single failure, whether link, node, or shared risk 
link group (SRLG). The goal of this technology is to reduce the 
packet loss that happens while routers converge after a topology 
change due to a failure. Rapid failure repair is achieved through 
use of precalculated backup next-hops that are loop-free and safe to 
use until the distributed network convergence process completes. 

This simple approach does not require any support from other routers. 
The extent to which this goal can be met by this specification is 
dependent on the topology of the network. 
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Introduction 


Applications for interactive multimedia services such as Voice over 
IP (VoIP) and pseudowires can be very sensitive to traffic loss, such 
as occurs when a link or router in the network fails. A router’s 
convergence time is generally on the order of hundreds of 
milliseconds; the application traffic may be sensitive to losses 
greater than tens of milliseconds. 


As discussed in [FRAMEWORK], minimizing traffic loss requires a 
mechanism for the router adjacent to a failure to rapidly invoke a 
repair path, which is minimally affected by any subsequent re- 
convergence. This specification describes such a mechanism that 
allows a router whose local link has failed to forward traffic to a 
pre-computed alternate until the router installs the new primary 
next-hops based upon the changed network topology. The terminology 
used in this specification is given in [FRAMEWORK]. The described 
mechanism assumes that routing in the network is performed using a 
link-state routing protocol -- OSPF [RFC2328] [RFC2740] [RFC5340] or 
IS-IS [RFC1195] [RFC2966] (for IPv4 or IPv6). The mechanism also 
assumes that both the primary path and the alternate path are in the 
same routing area. 


When a local link fails, a router currently must signal the event to 
its neighbors via the IGP, recompute new primary next-hops for all 
affected prefixes, and only then install those new primary next-hops 
into the forwarding plane. Until the new primary next-hops are 
installed, traffic directed towards the affected prefixes is 
discarded. This process can take hundreds of milliseconds. 
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Figure 1: Basic Topology 
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The goal of IP Fast Reroute (IPFRR) is to reduce failure reaction 
time to 10s of milliseconds by using a pre-computed alternate next- 
hop, in the event that the currently selected primary next-hop fails, 
so that the alternate can be rapidly used when the failure is 
detected. A network with this feature experiences less traffic loss 
and less micro-looping of packets than a network without IPFRR. 

There are cases where traffic loss is still a possibility since IPFRR 
coverage varies, but in the worst possible situation a network with 
IPFRR is equivalent with respect to traffic convergence to a network 
without IPFRR. 


To clarify the behavior of IP Fast Reroute, consider the simple 
topology in Figure 1. When router S computes its shortest path to 
router D, router S determines to use the link to router E as its 
primary next-hop. Without IP Fast Reroute, that link is the only 
next-hop that router S computes to reach D. With IP Fast Reroute, S 
also looks for an alternate next-hop to use. In this example, S 
would determine that it could send traffic destined to D by using the 
link to router N 1 and therefore S would install the link to N 1 as 
its alternate next-hop. At some later time, the link between router 
S and router E could fail. When that link fails, S and E will be the 
first to detect it. On detecting the failure, S will stop sending 
traffic destined for D towards E via the failed link, and instead 
send the traffic to S's pre-computed alternate next-hop, which is the 
link to N 1, until a new SPF is run and its results are installed. 

As with the primary next-hop, an alternate next-hop is computed for 
each destination. The process of computing an alternate next-hop 
does not alter the primary next-hop computed via a standard SPF. 


If in the example of Figure 1, the link cost from N 1 to D increased 
to 30 from 3, then N 1 would not be a loop-free alternate, because 
the cost of the path from N 1 to D via S would be 17 while the cost 
from N 1 directly to D would be 30. In real networks, we may often 
face this situation. The existence of a suitable loop-free alternate 
next-hop is dependent on the topology and the nature of the failure 
for which the alternate is calculated. 


This specification uses the terminology introduced in [FRAMEWORK]. 

In particular, it uses Distance opt(X,Y), abbreviated to D opt(X,Y), 
to indicate the shortest distance from X to Y. S is used to indicate 
the calculating router. N i is a neighbor of S; N is used as an 
abbreviation when only one neighbor is being discussed. D is the 
destination under consideration. 
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A neighbor N can provide a loop-free alternate (LFA) if and only if 
Distance opt(N, D) < Distance opt(N, S) + Distance_opt(S, D) 
Inequality 1: Loop-Free Criterion 


A subset of loop-free alternates are downstream paths that must meet 
a more restrictive condition that is applicable to more complex 
failure scenarios: 


Distance opt(N, D) « Distance opt(S, D) 
Inequality 2: Downstream Path Criterion 
1.1. Failure Scenarios 


The alternate next-hop can protect against a single link failure, a 
single node failure, failure of one or more links within a shared 
risk link group, or a combination of these. Whenever a failure 
occurs that is more extensive than what the alternate was intended to 
protect, there is the possibility of temporarily looping traffic 
(note again, that such a loop would only last until the next complete 
SPF calculation). The example where a node fails when the alternate 
provided only link protection is illustrated below. If unexpected 
simultaneous failures occur, then micro-looping may occur since the 
alternates are not pre-computed to avoid the set of failed links. 


If only link protection is provided and the node fails, it is 
possible for traffic using the alternates to experience micro- 
looping. This issue is illustrated in Figure 2. If Link(S->E) 
fails, then the link-protecting alternate via N will work correctly. 
However, if router E fails, then both S and N will detect a failure 


and switch to their alternates. In this example, that would cause S 
to redirect the traffic to N and N to redirect the traffic to S and 
thus causing a forwarding loop. Such a scenario can arise because 


the key assumption, that all other routers in the network are 
forwarding based upon the shortest path, is violated because of a 
second simultaneous correlated failure -- another link connected to 
the same primary neighbor. If there are not other protection 
mechanisms to handle node failure, a node failure is still a concern 
when only using link-protecting LFAs. 
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Figure 2: Link-Protecting Alternates Causing Loop on Node Failure 


Micro-looping of traffic via the alternates caused when a more 
extensive failure than planned for occurs can be prevented via 
selection of only downstream paths as alternates. A micro-loop due 
to the use of alternates can be avoided by using downstream paths 
because each succeeding router in the path to the destination must be 
closer to the destination than its predecessor (according to the 
topology prior to the failures). Although use of downstream paths 
ensures that the micro-looping via alternates does not occur, such a 
restriction can severely limit the coverage of alternates. In 
Figure 2, S would be able to use N as a downstream alternate, but N 
could not use S; therefore, N would have no alternate and would 
discard the traffic, thus avoiding the micro-loop. 


As shown above, the use of either a node-protecting LFA (described in 
Section 3.2) or a downstream path provides protection against micro- 
looping in the event of node failure. There are topologies where 
there may be either a node-protecting LFA, a downstream path, both, 
or neither. A node may select either a node-protecting LFA or a 
downstream path without risk of causing micro-loops in the event of 
neighbor node failure. While a link-and-node-protecting LFA 
guarantees protection against either link or node failure, a 
downstream path provides protection only against a link failure and 
may or may not provide protection against a node failure depending on 
the protection available at the downstream node, but it cannot cause 
a micro-loop. For example, in Figure 2, if S uses N as a downstream 
path, although no looping can occur, the traffic will not be 
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protected in the event of the failure of node E because N has no 
viable repair path, and it will simply discard the packet. However, 
if N had a link-and-node-protecting LFA or downstream path via some 
other path (not shown), then the repair may succeed. 


Since the functionality of link-and-node-protecting LFAs is greater 
than that of link-protecting downstream paths, a router SHOULD select 
a link-and-node-protecting LFA over a link-protecting downstream 
path. If there are any destinations for which a link-and-node- 
protecting LFA is not available, then by definition the path to all 
of those destinations from any neighbor of the computing router (S) 
must be through the node (E) being protected (otherwise there would 
be a node protecting LFA for that destination). Consequently, if 
there exists a downstream path to the protected node as destination, 
then that downstream path may be used for all those destinations for 
which a link-and-node-protecting LFA is not available; the existence 
of a downstream path can be determined by a single check of the 
condition Distance opt(N, E) « Distance opt(S, E). 


It may be desirable to find an alternate that can protect against 
other correlated failures (of which node failure is a specific 
instance). In the general case, these are handled by shared risk 
link groups (SRLGs) where any links in the network can belong to the 
SRLG. General SRLGs may add unacceptably to the computational 
complexity of finding a loop-free alternate. 


However, a sub-category of SRLGs is of interest and can be applied 
only during the selection of an acceptable alternate. This sub- 
category is to express correlated failures of links that are 
connected to the same router, for example, if there are multiple 
logical sub-interfaces on the same physical interface, such as VLANs 
on an Ethernet interface, if multiple interfaces use the same 
physical port because of channelization, or if multiple interfaces 
share a correlated failure because they are on the same line-card. 
This sub-category of SRLGs will be referred to as local-SRLGs. A 
local-SRLG has all of its member links with one end connected to the 
same router. Thus, router S could select a loop-free alternate that 
does not use a link in the same local-SRLG as the primary next-hop. 
The failure of local-SRLGs belonging to E can be protected against 
via node protection, i.e., picking a loop-free node-protecting 
alternate. 


Where SRLG protection is provided, it is in the context of the 
particular OSPF or IS-IS area, whose topology is used in the SPF 
computations to compute the loop-free alternates. If an SRLG 
contains links in multiple areas, then separate SRLG-protecting 
alternates would be required in each area that is traversed by the 
affected traffic. 
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1.2. Requirement Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Applicability of Described Mechanisms 


IP Fast Reroute mechanisms described in this memo cover intra-domain 
routing only, with OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS 
[RFC1195] [RFC2966] as the IGP. Specifically, Fast Reroute for BGP 
inter-domain routing is not part of this specification. 


Certain aspects of OSPF inter-area routing behavior explained in 
Section 6.3 and Appendix A impact the ability of the router 
calculating the backup next-hops to assess traffic trajectories. In 
order to avoid micro-looping and ensure required coverage, certain 
constraints are applied to multi-area OSPF networks: 


a.  Loop-free alternates should not be used in the backbone area if 
there are any virtual links configured unless, for each transit 
area, there is a full mesh of virtual links between all Area 
Border Routers (ABRs) in that area.  Loop-free alternates may be 
used in non-backbone areas regardless of whether there are 
virtual links configured. 


b. Loop-free alternates should not be used for inter-area routes in 
an area that contains more than one alternate ABR [RFC3509]. 


C.  Loop-free alternates should not be used for AS External routes or 
Autonomous System Border Router (ASBR) routes in a non-backbone 
area of a network where there exists an ABR that is announced as 
an ASBR in multiple non-backbone areas and there exists another 
ABR that is in at least two of the same non-backbone areas. 


d.  Loop-free alternates should not be used in a non-backbone area of 
a network for AS External routes where an AS External prefix is 
advertised with the same type of external metric by multiple 
ASBRs, which are in different non-backbone areas, with a 
forwarding address of 0.0.0.0 or by one or more ASBRs with 
forwarding addresses in multiple non-backbone areas when an ABR 
exists simultaneously in two or more of those non-backbone areas. 
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Alternate Next-Hop Calculation 


In addition to the set of primary next-hops obtained through a 
shortest path tree (SPT) computation that is part of standard link- 
state routing functionality, routers supporting IP Fast Reroute also 
calculate a set of backup next-hops that are engaged when a local 
failure occurs. These backup next-hops are calculated to provide the 
required type of protection (i.e., link-protecting and/or node- 
protecting) and to guarantee that when the expected failure occurs, 
forwarding traffic through them will not result in a loop. Such 
next-hops are called loop-free alternates or LFAs throughout this 
Specification. 


In general, to be able to calculate the set of LFAs for a specific 
destination D, a router needs to know the following basic pieces of 
information: 


o Shortest-path distance from the calculating router to the 
destination (Distance opt(S, D)) 


o Shortest-path distance from the router's IGP neighbors to the 
destination (Distance opt(N, D)) 


o Shortest path distance from the router’s IGP neighbors to itself 
(Distance opt(N, S)) 


o Distance opt(S, D) is normally available from the regular SPF 
calculation performed by the link-state routing protocols. 
Distance opt(N, D) and Distance opt(N, S) can be obtained by 
performing additional SPF calculations from the perspective of 
each IGP neighbor (i.e., considering the neighbor's vertex as the 
root of the SPT--called SPT(N) hereafter--rather than the 
calculating router's one, called SPT(S)). 


This specification defines a form of SRLG protection limited to those 
SRLGs that include a link to which the calculating router is directly 
connected. Only that set of SRLGs could cause a local failure; the 
calculating router only computes alternates to handle a local 
failure. Information about local link SRLG membership is manually 
configured. Information about remote link SRLG membership may be 
dynamically obtained using [RFC4205] or [RFCA4203]. Define 

SRLG local(S) to be the set of SRLGs that include a link to which the 
calculating router S is directly connected Only SRLG local(S) is of 
interest during the calculation, but the calculating router must 
correctly handle changes to SRLG local(S) triggered by local link 
SRLG membership changes. 
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In order to choose among all available LFAs that provide required 
SRLG protection for a given destination, the calculating router needs 
to track the set of SRLGs in SRLG_local(S) that the path through a 
specific IGP neighbor involves. To do so, each node D in the network 
topology is associated with SRLG_set(N, D), which is the set of SRLGs 
that would be crossed if traffic to D was forwarded through N. To 
calculate this set, the router initializes SRLG_set(N, N) for each of 
its IGP neighbors to be empty. During the SPT(N) calculation, when a 
new vertex V is added to the SPT, its SRLG_set(N, V) is set to the 
union of SRLG sets associated with its parents, and the SRLG sets in 
SRLG_local(S) that are associated with the links from V’s parents to 
V. The union of the set of SRLGs associated with a candidate 
alternate next-hop and the SRLG_set(N, D) for the neighbor reached 
via that candidate next-hop is used to determine SRLG protection. 


The following sections provide information required for calculation 
of LFAs. Sections 3.1 through 3.4 define different types of LFA 
conditions. Section 3.5 describes constraints imposed by the IS-IS 
overload and OSPF stub router functionality. Section 3.6 defines the 
summarized algorithm for LFA calculation using the definitions in the 
previous sections. 


.1. Basic Loop-Free Condition 


Alternate next hops used by implementations following this 
specification MUST conform to at least the loop-freeness condition 
stated above in Inequality 1. This condition guarantees that 
forwarding traffic to an LFA will not result in a loop after a link 
failure. 


Further conditions may be applied when determining link-protecting 
and/or node-protecting alternate next-hops as described in Sections 
3.2. and 3.3. 


.2.  Node-Protecting Alternate Next-Hops 


For an alternate next-hop N to protect against node failure of a 
primary neighbor E for destination D, N must be loop-free with 
respect to both E and D. In other words, N's path to D must not go 
through E. This is the case if Inequality 3 is true, where N is the 
neighbor providing a loop-free alternate. 


Distance opt(N, D) < Distance opt(N, E) + Distance opt (E, D) 


Inequality 3: Criteria for a Node-Protecting Loop-Free Alternate 
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If Distance opt(N,D) = Distance opt(N, E) + Distance opt(E, D), it is 
possible that N has equal-cost paths and one of those could provide 
protection against E's node failure. However, it is equally possible 
that one of N's paths goes through E, and the calculating router has 
no way to influence N's decision to use it. Therefore, it SHOULD be 
assumed that an alternate next-hop does not offer node protection if 
Inequality 3 is not met. 


3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links 


Verification of the link-protection property of a next-hop in the 
case of a broadcast link is more elaborate than for a point-to-point 
link. This is because a broadcast link is represented as a pseudo- 
node with zero-cost links connecting it to other nodes. 


Because failure of an interface attached to a broadcast segment may 
mean loss of connectivity of the whole segment, the condition 
described for broadcast link protection is pessimistic and requires 
that the alternate is loop-free with regard to the pseudo-node. 
Consider the example in Figure 3. 
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Figure 3: Loop-Free Alternate That Is Link-Protecting 
In Figure 3, N offers a loop-free alternate that is link-protecting. 
If the primary next-hop uses a broadcast link, then an alternate 
SHOULD be loop-free with respect to that link’s pseudo-node (PN) to 
provide link protection. This requirement is described in Inequality 
4 below. 
D opt (N, D) < D_opt(N, PN) + D opt (PN, D) 


Inequality 4: Loop-Free Link-Protecting Criterion for Broadcast Links 
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Because the shortest path from the pseudo-node goes through E, if a 
loop-free alternate from a neighbor N is node-protecting, the 
alternate will also be link-protecting unless the router S can only 
reach the alternate neighbor N via the same pseudo-node. Since this 
is the only case for which a node-protecting LFA is not link- 
protecting, this implies that for point-to-point interfaces, an LFA 
that is node-protecting is always link-protecting. Because S can 
direct the traffic away from the shortest path to use the alternate 
N, traffic might pass through the same broadcast link as it would 
when S sent the traffic to the primary E. Thus, an LFA from N that 
is node-protecting is not automatically link-protecting for a 
broadcast or NBMA link. 


To obtain link protection, it is necessary both that the path from 
the selected alternate next-hop does not traverse the link of 
interest and that the link used from S to reach that alternate next- 
hop is not the link of interest. The latter can only occur with non- 
point-to-point links. Therefore, if the primary next-hop is across a 
broadcast or NBMA interface, it is necessary to consider link 
protection during the alternate selection. To clarify, consider the 
topology in Figure 3. For N to provide link protection, it is first 
necessary that N’s shortest path to D does not traverse the pseudo- 
node PN. Second, it is necessary that the alternate next-hop 
selected by S does not traverse PN. In this example, S’s shortest 
path to N is via the pseudo-node. Thus, to obtain link protection, S 
must find a next-hop to N (the point-to-point link from S to N in 
this example) that avoids the pseudo-node PN. 


Similar consideration of the link from S to the selected alternate 
next-hop as well as the path from the selected alternate next-hop is 
also necessary for SRLG protection. S’s shortest path to the 
selected neighbor N may not be acceptable as an alternate next-hop to 
provide SRLG protection, even if the path from N to D can provide 
SRLG protection. 


3.4. ECMP and Alternates 


With Equal-Cost Multi-Path (ECMP), a prefix may have multiple primary 
next-hops that are used to forward traffic. When a particular 
primary next-hop fails, alternate next-hops should be used to 
preserve the traffic. These alternate next-hops may themselves also 
be primary next-hops, but need not be. Other primary next-hops are 
not guaranteed to provide protection against the failure scenarios of 
concern. 
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Figure 4: ECMP Where Primary Next-Hops Provide Limited Protection 


In Figure 4 S has three primary next-hops to reach D; these are L2 to 
El, L2 to E2, and L3 to E3. The primary next-hop L2 to El can obtain 
link and node protection from L3 to E3, which is one of the other 
primary next-hops; L2 to El cannot obtain link protection from the 
other primary next-hop L2 to E2. Similarly, the primary next-hop L2 
to E2 can only get node protection from L2 to El and can only get 
link protection from L3 to E3. The third primary next-hop L3 to E3 
can obtain link and node protection from L2 to El and from L2 to E2. 
It is possible for both the primary next-hop L2 to E2 and the primary 
next-hop L2 to El to obtain an alternate next-hop that provides both 
link and node protection by using L1. 


Alternate next-hops are determined for each primary next-hop 
Separately. As with alternate selection in the non-ECMP case, these 
alternate next-hops should maximize the coverage of the failure 
cases. 


3.5. Interactions with IS-IS Overload, RFC 3137, and Costed Out Links 


As described in [RFC3137], there are cases where it is desirable not 
to have a router used as a transit node. For those cases, it is also 
desirable not to have the router used on an alternate path. 


For computing an alternate, a router MUST NOT use an alternate next- 
hop that is along a link whose cost or reverse cost is LSInfinity 
(for OSPF) or the maximum cost (for IS-IS) or that has the overload 
bit set (for IS-IS). For a broadcast link, the reverse cost 
associated with a potential alternate next-hop is the cost towards 
the pseudo-node advertised by the next-hop router. For point-to- 
point links, if a specific link from the next-hop router cannot be 
associated with a particular link, then the reverse cost considered 
is that of the minimum cost link from the next-hop router back to S. 
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In the case of OSPF, if all links from router S to a neighbor N_i 
have a reverse cost of LSInfinity, then router S MUST NOT use N_i as 
an alternate. 


Similarly in the case of IS-IS, if N_i has the overload bit set, then 
S MUST NOT consider using N_i as an alternate. 


This preserves the desired behavior of diverting traffic away from a 
router that is following [RFC3137], and it also preserves the desired 
behavior when an operator sets the cost of a link to LSInfinity for 
maintenance that is not permitting traffic across that link unless 
there is no other path. 


If a link or router that is costed out was the only possible 
alternate to protect traffic from a particular router S toa 
particular destination, then there should be no alternate provided 
for protection. 


3.5.1. Interactions with IS-IS Link Attributes 


[RFC5029] describes several flags whose interactions with LFAs need 
to be defined. A router SHOULD NOT specify the "local protection 
available" flag as a result of having LFAs. A router SHOULD NOT use 
an alternate next-hop that is along a link for which the link has 
been advertised with the attribute "link excluded from local 
protection path" or with the attribute "local maintenance required". 


3.6. Selection Procedure 


A router supporting this specification SHOULD attempt to select at 
least one loop-free alternate next-hop for each primary next-hop used 
for a given prefix. A router MAY decide to not use an available 
loop-free alternate next-hop. A reason for such a decision might be 
that the loop-free alternate next-hop does not provide protection for 
the failure scenario of interest. 


The alternate selection should maximize the coverage of the failure 
cases. 


When calculating alternate next-hops, the calculating router S 
applies the following rules. 


1. S SHOULD select a loop-free node-protecting alternate next-hop, 


if one is available. If no loop-free node-protecting alternate 
is available, then S MAY select a loop-free link-protecting 
alternate. 
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2. If S has a choice between a loop-free link-and-node-protecting 
alternate and a loop-free node-protecting alternate that is not 
link-protecting, S SHOULD select a loop-free link-and-node- 
protecting alternate. This can occur as explained in 
Section 3.3. 


3. If S has multiple primary next-hops, then S SHOULD select as a 
loop-free alternate either one of the other primary next-hops or 
a loop-free node-protecting alternate if available. If no loop- 
free node-protecting alternate is available and no other primary 
next-hop can provide link-protection, then S SHOULD select a 
loop-free link-protecting alternate. 


4. Implementations SHOULD support a mode where other primary next- 
hops satisfying the basic loop-free condition and providing at 
least link or node protection are preferred over any non-primary 
alternates. This mode is provided to allow the administrator to 
preserve traffic patterns based on regular ECMP behavior. 


5. Implementations considering SRLGs MAY use SRLG protection to 
determine that a node-protecting or link-protecting alternate is 
not available for use. 


Following the above rules maximizes the level of protection and use 
of primary (ECMP) next-hops. 


Each next-hop is associated with a set of non-mutually-exclusive 
characteristics based on whether it is used as a primary next-hop to 
a particular destination D, and the type of protection it can provide 
relative to a specific primary next-hop E: 


Primary Path - The next-hop is used by S as primary. 


Loop-Free Node-Protecting Alternate - This next-hop satisfies 
Inequality 1 and Inequality 3. The path avoids S, S's primary 
neighbor E, and the link from S to E. 


Loop-Free Link-Protecting Alternate - This next-hop satisfies 
Inequality 1 but not Inequality 3. If the primary next-hop uses a 
broadcast link, then this next-hop satisfies Inequality 4. 


An alternate path may also provide none, some, or complete SRLG 
protection as well as node and link or link protection. For 
instance, a link may belong to two SRLGs G1 and G2. The alternate 
path might avoid other links in G1 but not G2, in which case the 
alternate would only provide partial SRLG protection. 


Atlas, et al. Standards Track [Page 15] 


RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008 


Below is an algorithm that can be used to calculate loop-free 
alternate next-hops. The algorithm is given for informational 
purposes, and implementations are free to use any other algorithm as 
long as it satisfies the rules described above. 


The following procedure describes how to select an alternate next- 
hop. The procedure is described to determine alternate next-hops to 
use to reach each router in the topology. Prefixes that are 
advertised by a single router can use the alternate next-hop computed 
for the router to which they are attached. The same procedure can be 
used to reach a prefix that is advertised by more than one router 
when the logical topological transformation described in Section 6.1 
is used. 


S is the computing router. S has neighbors N 1 to N j. A candidate 
next-hop is indicated by (outgoing link, neighbor) and the outgoing 
link must be bidirectionally connected, as is determined by the IGP. 
The candidate next-hops of S are enumerated as H 1 through H k. 
Recall that S may have multiple next-hops over different interfaces 
to a neighbor. H i.link refers to the outgoing link of that next-hop 
and H i.neighbor refers to the neighbor of that next-hop. 


For a particular destination router D, let S have already computed 
D opt(S, D), and for each neighbor N i, D opt(N i, D), D opt(N i, S), 
and D opt (Ni, N j), the distance from N i to each other neighbor 


N j, and the set of SRLGs traversed by the path D opt (N i, D). S 
should follow the below procedure for every primary next-hop selected 
to reach D. This set of primary next-hops is represented P 1 to P p. 


This procedure finds the alternate next-hop(s) for P i. 


First, initialize the alternate information for P i as follows: 


P i.alt next hops = {} 

P i.alt type = NONE 

P i.alt link-protect = FALSE 
P i.alt node-protect = FALSE 
P_i 


i.alt srlg-protect = {} 

For each candidate next-hop H_h, 

f; Initialize variables as follows: 
cand_type = NONE 
cand_link-protect = FALSE 


cand_node-protect FALSE 
cand srlg-protect B 
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2 If Hh is P i, skip it and continue to the next candidate next- 
hop. 

du If H h.link is administratively allowed to be used as an 
alternate, 


and the cost of H h.link is less than the maximum, 
and the reverse cost of H_h is less than the maximum, 
and H h.neighbor is not overloaded (for IS-IS), 

and H h.link is bidirectional, 


then H h can be considered as an alternate. Otherwise, skip it 
and continue to the next candidate next-hop. 


4. If D opt( H h.neighbor, D) >= D opt( H h.neighbor, S) + D opt(S, 
D), then H h is not loop-free. Skip it and continue to the next 
candidate next-hop. 


Då cand type = LOOP-FREE. 

6. If H_h is a primary next-hop, set cand_type to PRIMARY. 

52 If H h.link is not P i.link, set cand link-protect to TRUE. 

8. If D opt(H h.neighbor, D) « D opt(H h.neighbor, P i.neighbor) + 


D opt(P i.neighbor, D), set cand node-protect to TRUE. 


9. If the router considers SRLGs, then set the cand srlg-protect to 
the set of SRLGs traversed on the path from S via P i.link to 
P i.neighbor. Remove the set of SRLGs to which H h belongs from 
cand srlg-protect. Remove from cand srlg-protect the set of 
SRLGs traversed on the path from H h.neighbor to D. Now 
cand srlg-protect holds the set of SRLGs to which P i belongs 
and that are not traversed on the path from S via H h to D. 


10. If cand type is PRIMARY, the router prefers other primary next- 
hops for use as the alternate, and the P i.alt type is not 
PRIMARY, goto Step 20. 


11. If cand type is not PRIMARY, P i.alt type is PRIMARY, and the 
router prefers other primary next-hops for use as the alternate, 


then continue to the next candidate next-hop 


12. If cand node-protect is TRUE and P i.alt node-protect is FALSE, 
goto Paragraph 20. 


13. If cand link-protect is TRUE and P i.alt link-protect is FALSE, 
goto Step 20. 
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14. If cand_srlg-protect has a better set of SRLGs than 
P i.alt srlg-protect, goto Step 20. 


15. If cand srlg-protect is different from P i.alt srlg-protect, 
then select between H h and P i.alt next hops based upon 
distance, IP addresses, or any router-local tie-breaker. If Hh 
is preferred, then goto Step 20. If P i.alt next hops is 
preferred, skip H h and continue to the next candidate next-hop. 


16. If D opt(H h.neighbor, D) « D opt(P i.neighbor, D) and 
D opt(P i.alt next hops, D) >= D opt(P i.neighbor, D), then H h 
is a downstream alternate and P i.alt next hops is simply an 
LFA. Prefer H h and goto Step 20. 


17. Based upon the alternate types, the alternate distances, IP 
addresses, or other tie-breakers, decide if H h is preferred to 
P i.alt next hops. If so, goto Step 20. 


18. Decide if P i.alt next hops is preferred to Hh. If so, then 
Skip H h and continue to the next candidate next-hop. 


19. Add Hh into P i.alt next hops. Set P i.alt type to the better 
type of H h.alt type and P i.alt type. Continue to the next 
candidate next-hop. 


20. Replace the P i alternate next-hop set with H h as follows: 


i.alt next hops = (H h) 

i.alt type = cand type 

i.alt link-protect - cand link-protect 
ae 

i 


i.alt node-protect = cand node-protect 
i.alt srlg-protect - cand srlg-protect 


Continue to the next candidate next-hop. 
3.7. LFA Types and Trade-Offs 


LFAs can provide different amounts of protection, and the decision 
about which type to prefer is dependent upon network topology and 
other techniques in use in the network. This section describes the 
different protection levels and the trade-offs associated with each. 


1. Primary Next-hop: When there are equal-cost primary next-hops, 
using one as an alternate is guaranteed not to cause micro-loops 
involving S. Traffic flows across the paths that the network 
will converge to, but congestion may be experienced on the 
primary paths since traffic is sent across fewer. All primary 
next-hops are downstream paths. 
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2. Downstream Paths: A downstream path, unlike an LFA, is guaranteed 
not to cause a micro-loop involving S regardless of the actual 
failure detected. However, the expected coverage of such 
alternates in a network is expected to be poor. All downstream 
paths are LFAs. 


3. LFA: An LFA can have good coverage of a network, depending on 
topology. However, it is possible to get micro-loops involving S 
if an unprotected failure occurs (e.g., a node fails when the LFA 
only was link-protecting). 


The different types of protection are abbreviated as LP (link- 
protecting), NP (node-protecting), and SP (SRLG-protecting). 


a. LP, NP, and SP: If such an alternate exists, it gives protection 
against all failures. 


b. LP and NP only: Many networks may handle SRLG failures via 
another method or may focus on node and link failures as being 
more common. 


c. LP only: A network may handle node failures via a high- 
availability technique and be concerned primarily about 
protecting the more common link failure case. 


d. NP only: These only exist on interfaces that aren’t point-to- 
point. If link protection is handled in a different layer, then 
an NP alternate may be acceptable. 


3.8. A Simplification: Per-Next-Hop LFAs 


It is possible to simplify the computation and use of LFAs when 
solely link protection is desired by considering and computing only 
one link-protecting LFA for each next-hop connected to the router. 
All prefixes that use that next-hop as a primary will use the LFA 
computed for that next-hop as its LFA. 


Even a prefix with multiple primary next-hops will have each primary 
next-hop protected individually by the primary next-hop's associated 
LFA. That associated LFA might or might not be another of the 
primary next-hops of the prefix. 


This simplification may reduce coverage in a network. In addition to 
limiting protection for multi-homed prefixes (see Section 6.1), the 
computation per next-hop may also not find an LFA when one could be 
found for some of the prefixes that use that next-hop. 
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For example, consider Figure 4 where S has three ECMP next-hops, EL, 
E2, and E3 to reach D. For the prefix D, E3 can give link protection 
for the next-hops El and E2; El and E2 can give link protection for 
the next-hops E3. However, if one uses this simplification to 
compute LFAs for El, E2, and E3 individually, there is no link- 
protecting LFA for El. E3 and E2 can protect each other. 


4. Using an Alternate 
If an alternate next-hop is available, the router redirects traffic 


to the alternate next-hop in case of a primary next-hop failure as 
follows. 


When a next-hop failure is detected via a local interface failure or 
other failure detection mechanisms (see [FRAMEWORK]), the router 
SHOULD: 


1. Remove the primary next-hop associated with the failure. 


2. Install the loop-free alternate calculated for the failed next- 
hop if it is not already installed (e.g., the alternate is alsoa 
primary next-hop). 


Note that the router MAY remove other next-hops if it believes (via 
SRLG analysis) that they may have been affected by the same failure, 
even if it is not visible at the time of failure detection. 


The alternate next-hop MUST be used only for traffic types that are 
routed according to the shortest path. Multicast traffic is 
specifically out of scope for this specification. 


4.1. Terminating Use of Alternate 


A router MUST limit the amount of time an alternate next-hop is used 
after the primary next-hop has become unavailable. This ensures that 
the router will start using the new primary next-hops. It ensures 
that all possible transient conditions are removed and the network 
converges according to the deployed routing protocol. 


There are techniques available to handle the micro-forwarding loops 
that can occur in a networking during convergence. 


A router that implements [MICROLOOP] SHOULD follow the rules given 
there for terminating the use of an alternate. 


A router that implements [ORDERED-FIB] SHOULD follow the rules given 
there for terminating the use of an alternate. 
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It is desirable to avoid micro-forwarding loops involving S. An 


example illustrating the problem is given in Figure 5. If the link 
from S to E fails, S will use N1 as an alternate and S will compute 
N2 as the new primary next-hop to reach D. If S starts using N2 as 


soon as S can compute and install its new primary, it is probable 
that N2 will not have yet installed its new primary next-hop. This 
would cause traffic to loop and be dropped until N2 has installed the 
new topology. This can be avoided by S delaying its installation and 
leaving traffic on the alternate next-hop. 


4£----- + 
| N2 [-------- | 
ere 1 | \|/ 
| 4----- + @@> +----- + 
| ee EN 
10 4£----- + 10 4£----- + 
| | | 
| 1 | | | 
| | M/ 10 | 
MES N 
| = | \|/ 
4£----- + 
| | | 
| 1| | | 
| | \|/ | 
|o | 
|----| D |----—-—-———— 
4£----- + 


Figure 5: Example Where Continued Use of Alternate Is Desirable 


This is an example of a case where the new primary is not a loop-free 
alternate before the failure and therefore may have been forwarding 
traffic through S. This will occur when the path via a previously 
upstream node is shorter than the path via a loop-free alternate 
neighbor. In these cases, it is useful to give sufficient time to 
ensure that the new primary neighbor and other nodes on the new 
primary path have switched to the new route. 


If the newly selected primary was loop-free before the failure, then 

it is safe to switch to that new primary immediately; the new primary 
wasn’t dependent on the failure and therefore its path will not have 

changed. 


Given that there is an alternate providing appropriate protection and 


while the assumption of a single failure holds, it is safe to delay 
the installation of the new primaries; this will not create 
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6. 


forwarding loops because the alternate’s path to the destination is 
known to not go via S or the failed element and will therefore not be 
affected by the failure. 


An implementation SHOULD continue to use the alternate next-hops for 
packet forwarding even after the new routing information is available 
based on the new network topology. The use of the alternate next- 
hops for packet forwarding SHOULD terminate: 


a. if the new primary next-hop was loop-free prior to the topology 
change, or 


b. if a configured hold-down, which represents a worst-case bound on 
the length of the network convergence transition, has expired, or 


c. if notification of an unrelated topological change in the network 
is received. 


Requirements on LDP Mode 


Since LDP [RFC5036] traffic will follow the path specified by the 
IGP, it is also possible for the LDP traffic to follow the loop-free 
alternates indicated by the IGP. To do so, it is necessary for LDP 
to have the appropriate labels available for the alternate so that 
the appropriate out-segments can be installed in the forwarding plane 
before the failure occurs. 


This means that a Label Switching Router (LSR) running LDP must 
distribute its labels for the Forwarding Equivalence Classes (FECs) 
it can provide to all its neighbors, regardless of whether or not 
they are upstream. Additionally, LDP must be acting in liberal label 
retention mode so that the labels that correspond to neighbors that 
aren't currently the primary neighbor are stored. Similarly, LDP 
should be in downstream unsolicited mode, so that the labels for the 
FEC are distributed other than along the SPT. 


If these requirements are met, then LDP can use the loop-free 
alternates without requiring any targeted sessions or signaling 


extensions for this purpose. 


Routing Aspects 


.l. Multi-Homed Prefixes 


An SPF-like computation is run for each topology, which corresponds 
to a particular OSPF area or IS-IS level. The IGP needs to determine 
loop-free alternates to multi-homed routes.  Multi-homed routes occur 
for routes obtained from outside the routing domain by multiple 
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routers, for subnets on links where the subnet is announced from 
multiple ends of the link, and for routes advertised by multiple 
routers to provide resiliency. 


Figure 6 demonstrates such a topology. In this example, the shortest 
path to reach the prefix p is via E. The prefix p will have the link 
to E as its primary next-hop. If the alternate next-hop for the 
prefix p is simply inherited from the router advertising it on the 
shortest path to p, then the prefix p’s alternate next-hop would be 
the link to C. This would provide link protection, but not the node 
protection that is possible via A. 


------ | s [--=---| a [--=--| » | 
+---+ +---+ +---+ 

| | 

| 5 | 5 | 
| | | 
+---+ 5 +---+ 5 7 +---+ 
| e |---| £ |--- p --==-= | F | 
+---+  +---+ +---+ 


Figure 6: Multi-Homed Prefix 


To determine the best protection possible, the prefix p can be 
treated in the SPF computations as a node with unidirectional links 


to it from those routers that have advertised the prefix. Such a 
node need never have its links explored, as it has no out-going 
links. 


If there exist multiple multi-homed prefixes that share the same 
connectivity and the difference in metrics to those routers, then a 
single node can be used to represent the set. For instance, if in 
Figure 6 there were another prefix X that was connected to E with a 
metric of 1 and to F with a metric of 3, then that prefix X could use 
the same alternate next-hop as was computed for prefix p. 


A router SHOULD compute the alternate next-hop for an IGP multi-homed 
prefix by considering alternate paths via all routers that have 
announced that prefix. 


In all cases, a router MAY safely simplify the multi-homed prefix 
(MHP) calculation by assuming that the MHP is solely attached to the 
router that was its pre-failure optimal point of attachment. 

However, this may result in a prefix not being considered repairable, 
when the full computation would show that a repair was possible. 
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6.2.  IS-IS 


The applicability and interactions of LFAs with multi-topology IS-IS 
[RFC5120] is out of scope for this specification. 


6.3. OSPF 


OSPF introduces certain complications because it is possible for the 
traffic path to exit an area and then re-enter that area. This can 
occur whenever a router considers the same route from multiple areas. 
There are several cases where issues such as this can occur. They 
happen when another area permits a shorter path to connect two ABRs 
than is available in the area where the LFA has been computed. To 
clarify, an example topology is given in Appendix A. 


a. Virtual Links: These allow paths to leave the backbone area and 
traverse the transit area. The path provided via the transit 
area can exit via any ABR. The path taken is not the shortest 
path determined by doing an SPF in the backbone area. 


b. Alternate ABR [RFC3509]: When an ABR is not connected to the 
backbone, it considers the inter-area summaries from multiple 
areas. The ABR A may determine to use area 2 but that path could 
traverse another alternate ABR B that determines to use area 1. 
This can lead to scenarios similar to that illustrated in 
Figure 7. 


C.  ASBR Summaries: An ASBR may itself be an ABR and can be announced 


into multiple areas. This presents other ABRs with a decision as 
to which area to use. This is the example illustrated in 
Figure 7. 


d. AS External Prefixes: A prefix may be advertised by multiple 
ASBRs in different areas and/or with multiple forwarding 
addresses that are in different areas, which are connected via at 
least one common ABR. This presents such ABRs with a decision as 
to which area to use to reach the prefix. 


Loop-free alternates should not be used in an area where one of the 
above issues affects that area. 


6.3.1. OSPF External Routing 
When a forwarding address is set in an OSPF AS-external Link State 
Advertisement (LSA), all routers in the network calculate their next- 


hops for the external prefix by doing a lookup for the forwarding 
address in the routing table, rather than using the next-hops 


Atlas, et al. Standards Track [Page 24] 


RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008 


calculated for the ASBR. In this case, the alternate next-hops 

SHOULD be computed by selecting among the alternate paths to the 

forwarding link(s) instead of among alternate paths to the ASBR. 
6.3.2. OSPF Multi-Topology 


The applicability and interactions of LFAs with multi-topology OSPF 
[RFC4915] [MT-OSPFv3] is out of scope for this specification. 


6.4. BGP Next-Hop Synchronization 


Typically, BGP prefixes are advertised with the AS exit router’s 
router-id as the BGP next-hop, and AS exit routers are reached by 


means of IGP routes. BGP resolves its advertised next-hop to the 
immediate next-hop by potential recursive lookups in the routing 
database. IP Fast Reroute computes the alternate next-hops to all 


IGP destinations, which include alternate next-hops to the AS exit 
router’s router-id. BGP simply inherits the alternate next-hop from 
IGP. The BGP decision process is unaltered; BGP continues to use the 
IGP optimal distance to find the nearest exit router. Multicast BGP 
(MBGP) routes do not need to copy the alternate next-hops. 


It is possible to provide ASBR protection if BGP selected a set of 
BGP next-hops and allowed the IGP to determine the primary and 
alternate next-hops as if the BGP route were a multi-homed prefix. 
This is for future study. 


6.5. Multicast Considerations 


Multicast traffic is out of scope for this specification of IP Fast 
Reroute. The alternate next-hops SHOULD NOT be used for multicast 
Reverse Path Forwarding (RPF) checks. 


7. Security Considerations 


The mechanism described in this document does not modify any routing 
protocol messages, and hence no new threats related to packet 
modifications or replay attacks are introduced. Traffic to certain 
destinations can be temporarily routed via next-hop routers that 
would not be used with the same topology change if this mechanism 
wasn’t employed. However, these next-hop routers can be used anyway 
when a different topological change occurs, and hence this can’t be 
viewed as a new security threat. 


In LDP, the wider distribution of FEC label information is still to 
neighbors with whom a trusted LDP session has been established. This 
wider distribution and the recommendation of using liberal label 
retention mode are believed to have no significant security impact. 
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Appendix A. OSPF Example Where LFA Based on Local Area Topology Is 
Insufficient 


This appendix provides an example scenario where the local area 
topology does not suffice to determine that an LFA is available. As 
described in Section 6.3, one problem scenario is for ASBR summaries 
where the ASBR is available in two areas via intra-area routes and 
there is at least one ABR or alternate ABR that is in both areas. 
The following Figure 7 illustrates this case. 
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Figure 7: Topology with Multi-Area ASBR Causing Area Transiting 


In Figure 7, the ASBR is also an ABR and is announced into both area 
1 and area 2. A and B are both ABRs that are also connected to the 
backbone area. S determines that N can provide a loop-free alternate 
to reach the ASBR. N’s path goes via A. A also sees an intra-area 
route to ASBR via area 2; the cost of the path in area 2 is 30, which 
is less than 35, the cost of the path in area 1. Therefore, A uses 
the path from area 2 and directs traffic to F. The path from F in 
area 2 goes to B. B is also an ABR and learns the ASBR from both 
areas 1 and area 2; B’s path via area 1 is shorter (cost 20) than B’s 
path via area 2 (cost 25). Therefore, B uses the path from area 1 
that connects to S. 
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